IRIX Base Documentation 2001 May

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2001 May / SGI IRIX Base Documentation 2001 May.iso / usr / relnotes / eoe / chC.z / chC

Wrap

Text File | 2001-04-17 | 15.1 KB | 397 lines

- 1 - 1. _C_o_m_p_a_t_i_b_i_l_i_t_y This chapter contains information about compatibility issues within the IRIX6.x releases with respect to X/Open XPG4 compliance and Posix compliance and also presents information regarding structural changes within the IRIX6.x releases that those developing kernel-loaded filesystem code need to be aware of. 1.1 _X_P_G_4__c_o_m_p_a_t_i_b_i_l_i_t_y XPG4 compliance can be achieved by doing one of the following: 1. Installing the all platforms IRIX6.2 release along with the 6666....2222++++xxxxppppgggg4444 patch (patch 1125). 2. Installing the all platforms IRIX6.5 release. The default behavior for the IRIX6.2 and IRIX6.5 commands is non-X/Open XPG4 behavior which is traditional IRIX behavior. See the below discussion under ////ssssbbbbiiiinnnn////sssshhhh in order to obtain XPG4 behavior under the XPG4 compliant shell environment. 1.1.1 _/_s_b_i_n_/_s_h In order to obtain XPG4 behavior, the ////ssssbbbbiiiinnnn////sssshhhh shell must be used and the following environment variables must take on the below settings: eeeexxxxppppoooorrrrtttt ____XXXXPPPPGGGG====1111 uuuunnnnsssseeeetttt NNNNOOOOMMMMSSSSGGGGLLLLAAAABBBBEEEELLLL eeeexxxxppppoooorrrrtttt NNNNOOOOMMMMSSSSGGGGSSSSEEEEVVVVEEEERRRRIIIITTTTYYYY====1111 Please read the CCCCOOOOMMMMPPPPAAAATTTTIIIIBBBBIIIILLLLIIIITTTTYYYY IIIISSSSSSSSUUUUEEEESSSS section of the sssshhhh((((1111)))) man page for further discussion. 1.1.2 _/_s_b_i_n_/_s_e_d There are several items which could produce compatibility inconsistencies between traditional IRIX behavior and X/Open XPG4 behavior. 1.1.2.1 _s__a_n_d__l__c_o_m_m_a_n_d_s See the man page sssseeeedddd((((1111)))). 1.1.2.2 _e_s_c_a_p_e__c_h_a_r_a_c_t_e_r_s Since X/Open regular expressions were introduced starting in IRIX6.4, there are some differences which can occur with respect to the back-slash escape character. The below example shows this incompatibility. - 2 - sed -n -e "/searchfor/,/\};/p" filename The file 'filename' doesn't exist. Under IRIX6.2: ============== Can't open filename Under IRIX6.4 & 6.5 =================== sed: command garbled: /searchfor/,/\};/p The problem lies with the \} sequence because '\{' and '\}' are meaningful to the X/Open regular expressions. The sed script is in error by specifying '\}' and should just be '}'. See the BBBBaaaassssiiiicccc RRRReeeegggguuuullllaaaarrrr EEEExxxxpppprrrreeeessssssssiiiioooonnnnssss section from rrrreeeeggggccccoooommmmpppp((((5555)))). 1.1.3 _/_s_b_i_n_/_r_m The ----iiii and the ----ffff options if both specified have a defined XPG4 behavior. From the XPG4 specification: ----iiii ---- PPPPrrrroooommmmpppptttt ffffoooorrrr ccccoooonnnnffffiiiirrrrmmmmaaaattttiiiioooonnnn aaaassss ddddeeeessssccccrrrriiiibbbbeeeedddd pppprrrreeeevvvviiiioooouuuussssllllyyyy.... AAAAnnnnyyyy pppprrrreeeevvvviiiioooouuuussss ooooccccccccuuuurrrrrrrreeeennnncccceeeessss ooooffff tttthhhheeee ----ffff ooooppppttttiiiioooonnnn wwwwiiiillllllll bbbbeeee iiiiggggnnnnoooorrrreeeedddd.... E.g., rrrrmmmm ----ffff ----iiii behaves differently than rrrrmmmm ----iiii ----ffff. This is most of an issue with shell aliases or functions. 1.1.4 _/_u_s_r_/_b_i_n_/_l_o_c_a_l_e_d_e_f There is an incompatibility between generated versions of the LLLLCCCC____TTTTYYYYPPPPEEEE locale category prior to the IRIX 6.5 release and IRIX 6.5. That is, binary locales generated prior to IRIX 6.5 will not be recognized by IRIX 6.5 and must be regenerated with the IRIX 6.5 version of llllooooccccaaaalllleeeeddddeeeeffff((((1111)))). See the NNNNOOOOTTTTEEEE section in the llllooooccccaaaalllleeeeddddeeeeffff((((1111)))) man page. 1.1.5 _r_e_g_u_l_a_r__e_x_p_r_e_s_s_i_o_n_s In IRIX6.3 and earlier the below IRIX 6.x versions of the commands: sssseeeedddd,,,, eeeedddd,,,, eeeexxxx,,,, eeeexxxxpppprrrr,,,, vvvviiii,,,, ggggrrrreeeepppp,,,, eeeeggggrrrreeeepppp,,,, fffflllleeeexxxx,,,, aaaawwwwkkkk,,,, ffffiiiinnnndddd,,,, ppppaaaaxxxx,,,, mmmmoooorrrreeee all used the rrrreeeeggggeeeexxxxpppp((((5555)))) version of regular expressions. In IRIX6.4 and later versions of the above commands use the rrrreeeeggggccccoooommmmpppp((((5555)))) X/Open version of regular expressions. 1.1.6 _k_e_r_n_e_l__s_y_s_t_u_n_e_s The following systune variables must be set to be XPG4 compliant: ppppoooossssiiiixxxx____ttttttttyyyy____ddddeeeeffffaaaauuuulllltttt 1111 rrrreeeessssttttrrrriiiicccctttteeeedddd____cccchhhhoooowwwwnnnn 1111 - 3 - 1.1.7 _c_o_m_p_i_l_a_t_i_o_n__e_n_v_i_r_o_n_m_e_n_t The XPG4 compatible compiler is ////uuuussssrrrr////bbbbiiiinnnn////cccc88889999. The following command line options must be passed to the ////uuuussssrrrr////bbbbiiiinnnn////cccc88889999 compiler: ----DDDD____XXXXOOOOPPPPEEEENNNN____SSSSOOOOUUUURRRRCCCCEEEE ----UUUUuuuunnnniiiixxxx 1.1.8 _/_s_b_i_n_/_t_o_u_c_h There is a Y2K incompatibility issue with the ttttoooouuuucccchhhh command in IRIX releases prior to IRIX 6.5. Refer to the SGI Y2K web site (http://www.sgi.com/tech/year2000/) for information on SGI Y2K issues, as well as patches for this specific issue. See the ttttoooouuuucccchhhh((((1111)))) man page for the ----tttt option usage. In particular, the behavior of the frequently used kernel driver exitop (to force kernels to be rebuilt after new drivers are installed) ttttoooouuuucccchhhh 0000111100001111000000000000000000000000 is now different, and its use will cause kernels to not be rebuilt when they should. Instead use ttttoooouuuucccchhhh 111199997777000000001111000011110000000000000000. 1.2 _P_o_s_i_x__c_o_m_p_a_t_i_b_i_l_i_t_y 1.2.1 _k_e_r_n_e_l__s_y_s_t_u_n_e_s The following systune variables must be set to be POSIX compliant: ppppoooossssiiiixxxx____ttttttttyyyy____ddddeeeeffffaaaauuuulllltttt 1111 rrrreeeessssttttrrrriiiicccctttteeeedddd____cccchhhhoooowwwwnnnn 1111 1.3 _F_i_l_e_s_y_s_t_e_m__i_m_p_l_e_m_e_n_t_a_t_i_o_n__i_s_s_u_e_s Significant changes have been made in IRIX6.x releases that those implementing and maintaining kernel-loaded filesystems need to be particularly aware of: 1. In IRIX6.4, a behavior stacking model was introduced which changes substantially the structure of VOP and VFS op signatures and requires other changes in filesystem code designed to be loaded with the kernel. 2. In IRIX6.5, the requirements for the use of the behavior stacking code have been tightened, requiring changes in addition to the normal modification of filesystem code to adapt to additions or signature changes in the VOP and VFS interfaces between IRIX6.4 and IRIX6.5. 1.3.1 _B_e_h_a_v_i_o_r__s_t_a_c_k_i_n_g__m_o_d_e_l__i_n__I_R_I_X_6_._4 IRIX6.4 introduced new structures associated with v-objects such as vnodes and vfs's. These allow multiple layers of filesystem implementation to be stacked such that one layer may interpose on calls (such as VOP's) for the v-object. This structure has necessitated changes in external filesystem - 4 - code, even when the filesystem in question does not explicitly use any new features of this model. In IRIX6.4, the behavior head and behavior descriptor structures were introduced and the VOP and VFS interfaces were modified so that the initial parameter passed to the called ops functions was the behavior descriptor, rather then the v-object (vnode or vfs) itself. In addition, filesystems needed to link a behavior descriptor onto the behavior chain and remove the behavior descriptor at object initialization and destruction time respectively. For filesystems using non-VSHARE vnodes, (non-VSHARE vnode are those whose allocation is directly managed by the filesystem. VSHARE vnodes are managed in a global vnode pool shared by multiple filesystems), the filesystem needs to properly initialize the behavior head of the vnode immediately after it is allocated (using vn_bhv_head_init) and call a destroy function (vn_bhv_head_destroy) on the behavior head immediately before deallocating the vnode. If a filesystem implementation allocates its own vfs structures, similar requirements apply. The behavior head within the vfs should be initialized using bhv_head_init and bhv_head_destroy should be called before deallocating the memory of the vfs structure. This would be an unusual situation since typically the vfs is allocated by the kernel before calling the filesystem VFS_MOUNT routine and deallocated by the kernel after the filesystem's VFS_UNMOUNT routine has executed. See /usr/include/sys/vnode.h, /usr/include/sys/vfs.h, and /usr/include/ksys/behavior.h for a lot of relevant detail. 1.3.2 _F_u_r_t_h_e_r__r_e_q_u_i_r_e_m_e_n_t_s__f_o_r__I_R_I_X_6_._5 For filesystem code developed to run in an IRIX6.4 kernel environment, the major change has to do with requirements to intialize and destroy behavior head structures in non-VSHARE vnode and in vfs structures allocated by the filesystem itself. While this was also part of the interface for IRIX6.4, as described above, the implementation allowed filesystem code to run successfully without dealing properly with the behavior head structures. In particular, if the vnode (or an allocated vfs) was zeroed, the behavior head initialization did not need to be done and also, the destroy function was a no-op. In IRIX6.5, this is no longer the case, the behavior head for a non-VSHARE vnode must be properly initialized and destroyed. - 5 - Also note that it is more critical in IRIX6.5 that behaviors are properly unstacked before the objects associated with them are made available for dellocation. This may have gone unnnoticed in IRIX6.4. 1.3.3 _S_u_m_m_a_r_y _o_f _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _b_e_h_a_v_i_o_r _s_t_r_u_c_t_u_r_e _m_a_n_a_g_e_m_e_n_t 1.3.3.1 _F_o_r__n_o_n_-_V_S_H_A_R_E__v_n_o_d_e_s A filesystem should, after using vn_alloc: 1. Initialize its behavior descriptor using vn_bhv_desc_init. 2. Link the behavior descriptor into the behavior head using vn_bhv_insert_initial. A filesystem should remove its behavior descriptor using vn_bhv_remove before returning from a VOP_RECLAIM or VOP_INACTIVE returning VN_INACTIVE_NOCACHE or before doing a direct vn_free. 1.3.3.2 _F_o_r__n_o_n_-_V_S_H_A_R_E__v_n_o_d_e_s A filesystem should, after allocating a vnode: 1. Initialize its behavior descriptor using vn_bhv_desc_init. 2. Initialize the behavior head of a new vnode using vn_bhv_head_init. 3. Link the behavior descriptor into the behavior head using vn_bhv_insert_initial. Before deallocating a vnode, a filesystem should: 1. Remove its behavior descriptor using vn_bhv_remove. 2. Call vn_bhv_head_destroy on the behavior head for the vnode to be deallocated. 1.3.3.3 _F_o_r__n_o_r_m_a_l__(_i_._e__k_e_r_n_e_l_-_a_l_l_o_c_a_t_e_d_)__v_f_s__s_t_r_u_c_t_u_r_e_s At mount time, the filesystem should initialize its behavior descriptor and insert it in the vfs behavior head using vfs_insertbhv. At unmount time, the filesystem should remove its behavior descriptor from the vfs behavior head using VFS_REMOVEBHV. 1.3.3.4 _F_o_r _v_f_s _s_t_r_u_c_t_u_r_e_s _a_l_l_o_c_a_t_e_d _b_y _t_h_e _f_i_l_e_s_y_s_t_e_m _i_t_s_e_l_f After allocating such a vfs structure, the filesystem should: - 6 - 1. Initialize the behavior head within the vfs, using bhv_head_init. 2. Initialize its behavior descriptor and insert it in the vfs behavior head using vfs_insertbhv. Before deallocating such a vfs structure, the filesystem should: 1. Remove its behavior descriptor from the vfs behavior head using VFS_REMOVEBHV. 2. Use bhv_head_destroy on the behavior head for the vfs to get rid of any associated resources.